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Status of This Memo 


This document specifies an Internet Best Current Practices for the 
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Abstract 


Some IETF protocols make use of Ethernet frame formats and IEEE 802 
parameters. This document discusses some use of such parameters in 
IETF protocols and specifies IANA considerations for allocation of 

code points under the IANA OUI (Organizationally Unique Identifier). 
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Introduction 


Some IETF protocols use Ethernet or other [IEEE] 802 related 
communication frame formats and parameters [IEEE802]. These include 
MAC (Media Access Control) identifiers and protocol identifiers. 


This document specifies IANA considerations for the allocation of 
code points under the IANA OUI. It also discusses some other IETF 
use of IEEE 802 code points. 


[RFC5226] is incorporated herein except where there are contrary 
provisions in this document. 


-l. Notations Used in This Document 


This document uses hexadecimal notation. Each octet (that is, 8-bit 
byte) is represented by two hexadecimal digits giving the value of 
the octet as an unsigned integer. Successive octets are separated by 
a hyphen. This document consistently uses IETF bit ordering although 
the physical order of bit transmission within an octet on an IEEE 
[802.3] link is from the lowest order bit to the highest order bit 
(i.e., the reverse of the IETF’s ordering). 


In this document: 


"TAB" stands for Individual Address Block, not for Internet 
Architecture Board; 


"MAC" stands for Media Access Control, not for Message Authentication 
Code; and 


"OUI" stands for Organizationally Unique Identifier. 


"xx" indicates exponentiation. For example, 2**24 is two to the 
twenty-fourth power. 


-2. The IEEE Registration Authority 


Originally the responsibility of Xerox Corporation, the registration 
authority for Ethernet parameters is now the IEEE Registration 
Authority, available on the web at: 


http://standards.ieee.org/regauth/ 


Anyone may apply to that Authority for parameters. They may impose 
fees or other requirements but commonly waive fees for applications 
from standards development organizations. 
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2. 


Zi 


A list of some allocated OUIs and IABs and their holders is 
downloadable from the IEEE Registration Authority site. 


.2.1. The IANA OUI 


The OUI 00-00-5E has been allocated to IANA. 
3. Acknowledgements 
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Ethernet Identifier Parameters 


Section 2.1 discusses EUI-48 (Extended Unique Identifier 48) MAC 
identifiers, their relationship to OUIs and IABs, and allocations 
under the IANA OUI. Section 2.2 extends this to EUI-64 identifiers. 
Section 2.3 discusses other IETF MAC identifier use not under the 
IANA OUI. 


1. 48-Bit MAC Identifiers and OUIs 


48-bit MAC "addresses" are the most commonly used Ethernet interface 
identifiers. Those that are globally unique are also called EUI-48 
identifiers. An EUI-48 is structured into an initial 3-octet OUI 
(Organizationally Unique Identifier) and an additional 3 octets 
assigned by the OUI holder. For organizations not requiring 3 
octets’ worth of identifiers, the IEEE allocates IABs (Individual 
Address Blocks) instead, where the first 4 1/2 octets (36 bits) are 
assigned, giving the holder of the IAB 1 1/2 octets (12 bits) they 
can control. 


The IEEE describes its assignment procedures and policies for IEEE 
802 related identifiers in [802_08A]. 


Two bits within the initial 3 octets of an EUI-48 have special 
Significance: the Group bit (01-00-00) and the Local bit (02-00-00). 
OUIs and IABs are allocated with the Local bit zero and the Group bit 
unspecified. Multicast identifiers may be constructed by turning on 
the Group bit, and unicast identifiers constructed by leaving the 
Group bit zero. 
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For globally unique EUI-48 identifiers allocated by an OUI or IAB 
owner, the Local bit is zero. If the Local bit is a one, the 
identifier is considered by IEEE 802 to be a local identifier under 
the control of the local network administrator. If the Local bit is 
on, the holder of an OUI (or IAB) has no special authority over 
48-bit MAC identifiers whose first 3 (or 4 1/2) octets correspond to 
their OUI (or IAB). 


2.1.1. EUI-48 Allocations under the IANA OUI 


The OUI 00-00-5E has been assigned to IANA as stated in Section 1.2.1 
above. This includes 2**24 EUI-48 multicast identifiers from 
01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF and 2**24 EUI-48 unicast 
identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF. 


Of these EUI-48 identifiers, the following allocations have been made 
thus far: 


o The 2**23 multicast identifiers from 01-00-5E-00-00-00 through 
01-00-5E-7F-FF-FF have been allocated for IPv4 multicast 
[RFC1112]. 


o The 2**20 multicast identifiers from 01-00-5E-80-00-00 through 
01-00-5E-8F-FF-FF have been allocated for MPLS multicast 
[RFC5332]. 


o The 2**8 unicast identifiers from 00-00-5E-00-00-00 through 
00-00-5E-00-00-FF are reserved and require IESG Ratification 
for allocation (see Section 5.1). 


o The 2**8 unicast identifiers from 00-00-5E-00-01-00 through 
00-00-5E-00-01-FF have been allocated for the Virtual Router 
Redundancy Protocol (VRRP) [RFC3768]. 

2.1.2. EUI-48 IANA Allocation Considerations 


EUI-48 allocations under the current or a future IANA OUI (see 
Section 5.2) must meet the following requirements: 


o must be for standards purposes (either for an IETF Standard or 
other standard related to IETF work), 


o must be for a block of a power-of-two identifiers starting at a 
boundary that is an equal or greater power of two, including 


the allocation of one (2**0) identifier, 


o must not be used to evade the requirement for vendors to obtain 
their own block of identifiers from the IEEE, and 
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o must be documented in an Internet-Draft or RFC. 


In addition, approval must be obtained as follows (see the procedure 
in Section 5.1): 


Small to medium allocations of a block of 1, 2, 4, ..., 32768, 
65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers 
require Expert Review. 


Large allocations of 131072 (2**17) or more EUI-48 identifiers 
require IESG Ratification (see Section 5.1). 


To simplify record keeping, all future allocations of 256 (2**8) or 
fewer identifiers shall have the Group bit unspecified, that is, 
shall be allocations of parallel equal-size blocks of multicast and 
unicast identifiers, even if one of these two types is not needed for 
the proposed use. The only exception is that requests for unicast- 
only identifier blocks of any size may be allocated out of the 
remaining identifiers in the large unicast range from 
00-00-5E-00-02-00 to 00-00-DE-8F-FF-FF. 


Didi 64-Bit MAC Identifiers 


IEEE also defines a system of 64-bit MAC identifiers including 
EUI-64s. Uptake of these "MAC-64" identifiers has been limited. 
They are currently used in constructing some IPv6 Interface 
Identifiers as described below and by the following IEEE standards: 


o IEEE 1394 (also known as FireWire and i.Link), 
o IEEE 802.15.4 (also known as ZigBee). 


Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI forms 
an EUI-64 identifier under that OUI. As with EUI-48 identifiers, the 
OUI has the same Group/unicast and Local/Global bits. 


The discussion below is almost entirely in terms of the "Modified" 
form of EUI-64 identifiers; however, anyone allocated such an 
identifier also has the unmodified form and may use it as a MAC 
identifier on any link that uses such 64-bit identifiers for 
interfaces. 


2.2.1. IPv6 Use of Modified EUI-64 Identifiers 
MAC-64 identifiers are used to form the lower 64 bits of some IPv6 
addresses (Section 2.5.1 and Appendix A of [RFC4291] and Appendix A 


of [RFC5214]). When so used, the MAC-64 is modified by inverting the 
Local/Global bit to form an IETF "Modified EUI-64 identifier". Below 
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is an illustration of a Modified EUI-64 identifier under the IANA 
OUI, where aa-bb-cc-dd-ee is the extension. 


02-00-5E-aa-bb-cc-dd-ee 


The first octet is shown as 02 rather than 00 because, in Modified 
EUI-64 identifiers, the sense of the Local/Global bit is inverted 
compared with EUI-48 identifiers. It is the globally unique values 
(universal scope) that have the 02 bit on in the first octet, while 
those with this bit off are locally assigned and out of scope for 
global allocation. 


The Local/Global bit was inverted to make it easier for network 
operators to type in local-scope identifiers. Thus, such Modified 
EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros), are 
local. Without the modification, they would have to be 
02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc., to be local. 


As with MAC-48 identifiers, the 01 bit on in the first octet 
indicates a group identifier. 


When the first two octets of the extension of a Modified EUI-64 
identifier are FF-FE, the remainder of the extension is a 24-bit 
value as assigned by the OUI owner for an EUI-48. For example: 


02-00-5E-FF-FE-yy-yy-yy 
or 
03-00-5E-FF-FE-yy-yy-yy 


where yy-yy-yy is the portion (of an EUI-48 global unicast or 
multicast identifier) that is assigned by the OUI owner (IANA in this 
case). Thus, any holder of one or more EUI-48 identifiers under the 
IANA OUI also has an equal number of Modified EUI-64 identifiers that 
can be formed by inserting FF-FE in the middle of their EUI-48 
identifiers and inverting the Local/Global bit. 


(Note: [EUI-64] defines FF-FF as the bits to be inserted to create 
an IEEE EUI-64 identifier from a MAC-48 identifier. That document 
says the FF-FE value is used when starting with an EUI-48 
identifier. The IETF uses only FF-FE to create Modified EUI-64 
identifiers from 48-bit Ethernet station identifiers regardless of 
whether they are EUI-48 or MAC-48 local identifiers. EUI-48 and 
local MAC-48 identifiers are syntactically equivalent, and this 
doesn’t cause any problems in practice.) 
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In addition, certain Modified EUI-64 identifiers under the IANA OUI 
are reserved for holders of IPv4 addresses as follows: 


02-00-5E-FE-XX-XX-XX-XX 
where XX-XX-XX-XX is a 32-bit IPv4 address. For Modified EUI-64 
identifiers based on an IPv4 address, the Local/Global bit should be 
set to correspond to whether the IPv4 address is local or global. 
(Keep in mind that the sense of the Modified EUI-64 identifier 
Local/Global bit is reversed from that in (unmodified) MAC-64 
identifiers.) 


2.2.2. EUI-64 IANA Allocation Considerations 


The following table shows which Modified EUI-64 identifiers under the 
IANA OUI are reserved, used, or available as indicated. 


02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved 


02-00-5E-10-00-00-00-00 to 02-00-5E-EF-FF-FF-FF-FF available for 
allocation 


02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved 


02-00-5E-FE-00-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF used by IPv4 
address holders as described above 


02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved 


02-00-5E-FF-FE-00-00-00 to 02-00-5E-FF-FE-FF-FF-FF used by holders 
of EUI-48 identifiers under the IANA OUI as described above 


02-00-5E-FF-FF-00-00-00 to 02-00-5E-FF-FF-FF-FF-FF reserved 


The reserved identifiers above require IESG Ratification (see Section 
5.1) for allocation. IANA EUI-64 identifier allocations under the 
IANA OUI must meet the following requirements: 


o must be for standards purposes (either for an IETF Standard or 
other standard related to IETF work), 


o must be for a block of a power-of-two identifiers starting at a 
boundary which is an equal or greater power of two, including 


the allocation of one (2**0) identifier, 


o must not be used to evade the requirement for vendors to obtain 
their own block of identifiers from the IEEE, and 
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o must be documented in an Internet Draft or RFC. 


In addition, approval must be obtained as follows (see the procedure 
in Section 5.1): 


Small to medium allocations of a block of 1, 2, 4, ..., 134217728, 
268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64 
identifiers require Expert Review. 


Allocations of any size, including 536870912 (2**29) or more 
EUI-64 identifiers, may be made with IESG Ratification (see 
Section 5.1). 


To simplify record keeping, all allocations of 65536 (2**16) or less 
EUI-64 identifiers shall have the Group bit unspecified, that is, 
shall be allocations of parallel equal size blocks of multicast and 
unicast identifiers, even if one of these two types is not needed for 
the proposed use. 


2.3. Other MAC-48 Identifiers Used by IETF 


There are two other blocks of MAC-48 identifiers that are used by the 
IETF as described below. 


2.3.1. Identifiers Prefixed 33-33 


All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 
multicast MAC identifiers in the range from 33-33-00-00-00-00 to 
33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast 
[RFC2464]. In all these identifiers, the Group bit (the bottom bit 
of the first octet) is on, as is required to work properly with 
existing hardware as a multicast identifier. They also have the 
Local bit on and are used for this purpose in IPv6 networks. 


(Historical note: It was the custom during IPv6 design to use "3" 
for unknown or example values, and 3333 Coyote Hill Road, Palo 
Alto, California, is the address of PARC (Palo Alto Research 
Center, formerly "Xerox PARC"). Ethernet was originally specified 
by Digital Equipment Corporation, Intel Corporation, and Xerox 
Corporation. The pre IEEE [802.3] Ethernet protocol has sometimes 
been known as "DIX" Ethernet from the first letters of the names 
of these companies.) 
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2.3.2. The “CF Series’ 


The Informational [RFC2153] declared the 3-octet values from CF-00-00 
through CF-FF-FF to be OUls available for allocation by IANA to 
software vendors for use in PPP [RFC1661] or for other uses where 
vendors do not otherwise need an IEEE-assigned OUI. It should be 
noted that, when used as MAC-48 prefixes, these values have the Local 
and Group bits on, while all IEEE-allocated OUIs have those bits off. 
The Group bit is meaningless in PPP. To quote [RFC2153]: "The 
'CFO000’ series was arbitrarily chosen to match the PPP NLPID 'CF', 
as a matter of mnemonic convenience." 


CF-00-00 is reserved, and IANA lists multicast identifier 
CF-00-00-00-00-00 as used for Ethernet loopback tests. 


In over a decade of availability, only a handful of values in the 'CF 
Series’ have been allocated. (See http://www.iana.org under both 
Ethernet Parameters and PPP Parameters.) 


2.3.2.1. Changes to RFC 2153 
The IANA Considerations in [RFC2153] are updated as follows (no 
technical changes are made): Use of these identifiers based on IANA 
allocation is deprecated. IANA is directed not to allocate any 
further values in the ’CF Series’. 


3. Ethernet Protocol Parameters 


Ethernet protocol parameters provide a means of indicating the 


contents of a frame -- for example, that its contents are IPv4 or 
IPv6. 
The concept has been extended to labeling by "tags". A tag in this 


sense is a prefix whose type is identified by an Ethertype that is 
then followed by either another tag, an Ethertype, or an LSAP 
protocol indicator for the "main" body of the frame, as described 
below. Traditionally in the [802_08£A] world, tags are fixed length 
and do not include any encoding of their own length. Thus, anything 
that is processing a frame Cannot, in general, safely process 
anything in the frame past an Ethertype it does not understand. An 
example is the C-tag (formerly the O-tag) [802.10]. It provides 
customer VLAN and priority information for a frame. 


There are two types of protocol identifier parameters that can occur 


in Ethernet frames after the initial MAC-48 destination and source 
identifiers: 
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Ethertypes: These are 16-bit identifiers appearing as the initial 
two octets after the MAC destination and source (or after a 
tag) which, when considered as an unsigned integer, are equal 
to or larger than 0x0600. 


LSAPs: These are 8-bit protocol identifiers that occur in pairs 
immediately after an initial 16-bit (two octet) remaining frame 
length, which is in turn after the MAC destination and source 
(or after a tag). Such a length must, when considered as an 
unsigned integer, be less than 0x5DC or it could be mistaken as 
an Ethertype. LSAPs (Link-Layer Subnet Access Points) occur in 
pairs where one is intended to indicate the source protocol 
handler and one the destination protocol handler; however, use 
cases where the two are different have been relatively rare. 


Neither Ethertypes nor LSAPs are allocated by IANA; instead, they are 
allocated by the IEEE Registration Authority (see Section 1.2 above 
and the Ethertype Annex below). However, both LSAPs and Ethertypes 
have extension mechanisms so that they can be used with five-octet 
Ethernet protocol identifiers under an OUI, including those allocated 
by IANA under the IANA OUI. 


When using the IEEE 802 LLC format (SNAP) [802_08A] for a frame, an 
OUI-based protocol identifier can be expressed as follows: 


XX—-xXx-AA-AA-03-yy-yy-yy-ZZ-ZzZ 


where xx-xx is the frame length and, as above, must be small enough 
not to be confused with an Ethertype; "AA" is the LSAP that indicates 
this use and is sometimes referred to as the SNAP SAP; "03" is the 
LLC control octet indicating datagram service; yy-yy-yy is an OUI; 
and zz-zz is a protocol number, under that OUI, allocated by the OUI 
owner. The odd five-octet length for such OUI-based protocol 
identifiers was chosen so that, with the LLC control octet ("03"), 
the result is 16-bit aligned. 


When using an Ethertype to indicate the main type for a frame body, 
the special "OUI Extended Ethertype" 88-B7 is available. Using this 
Ethertype, a frame body can begin with 


88-B7-yy-yy-yy-ZZ-Zz 


where yy-yy-yy and zz-zz have the same meaning as in the SNAP format 
described above. 


It is also possible, within the SNAP format, to use an arbitrary 


Ethertype. Putting the Ethertype as the zz-zz field after an all 
zeros OUI (00-00-00) does this. It looks like 
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XX-XX-AA-AA-03-00-00-00-zz-zZ 
where zz-zz is the Ethertype. 
(Note that, at this point, the 802 protocol syntax facilities are 
sufficiently powerful that they could be chained indefinitely. 
Whether support for such chaining is generally required is not 
clear, but [802_08A] requires support for 
XX-XX-AA-AA-03-00-00-00-88-B7-YyY-YY-YY-ZZ-ZZ 


even though this could be more efficiently expressed by simply 
pinching out the "00-00-00-88-B7" in the middle.) 


As well as labeling frame contents, 802 Protocol types appear within 
NBMA (Non-Broadcast Multi-Access) Next Hop Resolution Protocol 
[RFC2332] messages. Such messages have provisions for both two octet 
Ethertypes and OUI based protocol types. 


3.1. Ethernet Protocol Allocation under the IANA OUI 
Two-octet protocol numbers under the IANA OUI are available, as in 
XxX—-XxX-AA-AA-03-00-00-5E-zz-zz. 


A number of such allocations have been made out of the 2**16 protocol 
numbers available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see [IANA]). 
The extreme values of this range, 00-00-5E-00-00 and 00-00-5E-FF-FF, 
are reserved and require IESG Ratification for allocation (see 
Section 5.1). New allocations of SNAP SAP protocol (zz-zz) numbers 
under the IANA OUI must meet the following requirements: 


o the allocation must be for standards use (either for an IETF 
Standard or other standard related to IETF work), 


o it must be documented in an Internet-Draft or RFC, and 
o such protocol numbers are not to be allocated for any protocol 


that has an Ethertype (because that can be expressed by putting 
an all zeros "OUI" before the Ethertype as described above). 


In addition, the Expert Review (or IESG Ratification for the two 
reserved values) must be obtained using the procedure specified in 
Section 5.1. 
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4. 


Other OUI-Based Parameters 


Some IEEE 802 and other protocols provide for parameters based on an 
OUI beyond those discussed above. Such parameters most commonly 
consist of an OUI plus one octet of additional value. They are 
usually called "vendor specific" parameters, although "organization 
specific" might be more accurate. They would look like 


YY-YY-YY~2z 


where yy-yy-yy is the OUI and zz is the additional specifier. An 
example is the Cipher Suite Selector in IEEE 802.11 ([802.11], page 
125). 


Values may be allocated under the IANA OUI for such other OUI-based 
parameter usage by Expert Review except that, for each use, the 
additional specifier values consisting of all zero bits and all one 
bits (0x00 and OxFF for a one-octet specifier) are reserved and 
require IESG Ratification (see Section 5.1) for allocation. The 
allocations must be for standards use (either for an IETF Standard or 
other standard related to IETF work) and be documented in an 
Internet-Draft or RFC. The first time a value is allocated for a 
particular parameter of this type, an IANA registry will be created 
to contain that allocation and any subsequent allocations of values 
for that parameter under the IANA OUI. The Expert will specify the 
name of the registry. 


(If a different policy from that above is required for such a 
parameter, a BCP or Standards Track RFC must be adopted updating this 
BCP and specifying the new policy and parameter.) 
IANA Considerations 
The entirety of this document concerns IANA Considerations for the 
allocation of Ethernet parameters in connection with the IANA OUI and 
related matters. 
Specifically: 
Section 1.2.1 provides information on the IANA-assigned OUI. 


Section 2.1.1 lists current EUI-48 assignments under this OUI. 


Section 2.1.2 specifies IANA considerations for EUI-48 
assignments. 


Section 2.2.2 specifies IANA considerations for EUI-64 
assignments. 
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Section 3.1 provides a pointer to current protocol identifier 
assignments under the IANA OUI, and specifies IANA considerations 
for protocol identifier assignments. 


Section 4 briefly provides IANA considerations relating to OUI- 
based miscellaneous allocations. 


5.1. Expert Review and IESG Ratification 


This section specifies the procedure for Expert Review and IESG 
Ratification of MAC, protocol, and other IANA OUI-based identifiers. 
The Expert (s) referred to in this document shall consist of one or 
more persons appointed by and serving at the pleasure of the IESG. 
The procedure described for Expert Review allocations in this 
document is fully consistent with the IANA Expert Review policy 
described in Section 4.1 of [RFC5226]. 


While finite, the universe of code points from which Expert judged 
allocations will be made is felt to be large enough that the 
requirements given in this document and the Experts’ good judgment 
are sufficient guidance. The idea is for the Expert to provide a 
light sanity check for small allocations of EUI identifiers with 
increased scrutiny by the Expert for medium-sized allocations of EUI 
identifiers, and allocations of protocol identifiers and other IANA 
OUI based parameters. However, it can make sense to allocate very 
large portions of the MAC identifier code point space. (Note that 
existing allocations include one for 1/2 of the entire multicast code 
point space and one for 1/16 of the multicast code point space.) In 
those cases, and in cases of the allocation of "reserved" values, 
IESG Ratification of an Expert Review approval recommendation is 
required as described below. The procedure is as follows: 


The applicant always completes the appropriate Template from the 
Template Annex below and sends it to IANA <iana@iana.org>. 


IANA always sends the Template to an appointed Expert. If the 
Expert recuses themselves or is non-responsive, IANA may choose 
an alternative appointed Expert or, if none are available, will 
contact the IESG. 


If the allocation is based on Expert Review: 


If IANA receives a disapproval from an Expert selected to 
review an application Template, the application will be 
denied. 

If IANA receives approval and code points are available, IANA 
will make the requested allocation. 
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If the allocation is based on IESG Ratification, the procedure 
starts with the first two steps above for Expert Review. If 
the Expert disapproves the application, they simply inform 
IANA; however, if the Expert believes the application should be 
approved, or is uncertain and believes that the circumstances 
warrant the attention of the IESG, the Expert will inform IANA 
about their advice and IANA will forward the application, 
together with the reasons for approval or uncertainty, to the 
IESG. The IESG must decide whether the allocation will be 
granted. This can be accomplished by a management item in an 
IESG telechat as done for other types of requests. If the IESG 
decides not to ratify a favorable opinion by the Expert or 
decides against an application where the Expert is uncertain, 
the application is denied, otherwise it is granted. The IESG 
will communicate its decision to the Expert and to IANA. 


5.2. Informational IANA Web Page Material 


IANA also maintains an informational listing on its web site 
concerning Ethertypes, OUIs, and multicast addresses allocated under 
OUIs other than the IANA OUI. IANA shall update that list when 
changes are provided by the Expert. 


5.3. OUI Exhaustion 


When the available space for either multicast or unicast EUI-48 
identifiers under OUI 00-00-5E have been 90% or more exhausted, IANA 
should request an additional OUI from the IEEE Registration Authority 
(see Section 1.2) for further IANA allocation use. 


6. Security Considerations 
This document is concerned with allocation of parameters under the 
IANA OUI and closely related matters. It is not directly concerned 
with security. 
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Appendix A. Templates 


A. 


i 


This annex provides the specific templates for IANA allocations of 
parameters. Explanatory words in parenthesis in the templates below 
may be deleted in a completed template as submitted to IANA. 


EUI-48/EUI-64 Identifier or Identifier Block Template 
Applicant Name: 

Applicant Email: 

Applicant Telephone: (starting with country code) 

Use Name: (brief name of Parameter use such as "Foo Protocol") 


Document: (ID or RFC specifying use to which the identifier or 
block of identifiers will be put.) 


Specify whether this is an application for EUI-48 or EUI-64 
identifiers: 


Size of Block requested: (must be a power-of-two-sized block, can 
be a block of size one (2**0)) 


Specify multicast, unicast, or both: 

5-Octet Ethernet Protocol Identifier Template 

Applicant Name: 

Applicant Email: 

Applicant Telephone: (starting with country code) 

Use Name: (brief name of use of code point such as "Foo Protocol") 


Document: (ID or RFC specifying use to which the protocol 
identifier will be put.) 
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A.3. Other IANA OUI-Based Parameter Template 
Applicant Name: 
Applicant Email: 
Applicant Telephone: (starting with country code) 


Protocol where the OUI Based Parameter for which a value is being 
requested appears: (such as: Cipher Suite selection in IEEE 
802.11) 


Use Name: (brief name of use of code point to be allocated, such 
as "Foo Cipher Suite") 


Document: (ID or RFC specifying use to which the other IANA OUI 
based parameter value will be put.) 


Appendix B. Ethertypes 


This annex lists some Ethertypes specified for IETF Protocols or by 
IEEE 802 as known at the time of publication. A more up-to-date list 
may be available on the IANA web site, currently at [IANA]. The IEEE 
Registration Authority page of Ethertypes, 
http://standards.ieee.org/regauth/ethertype/eth.txt, may also be 
useful. See Section 3 above. 


B.1. Some Ethertypes Specified by the IETF 


0x0800 Internet Protocol Version 4 (IPv4) 

0x0806 Address Resolution Protocol (ARP) 

0x0808 Frame Relay ARP 

0x880B Point-to-Point Tunneling Protocol (PPTP) 
Ox880C General Switch Management Protocol (GSMP) 
0x8035 Reverse Address Resolution Protocol (RARP) 
Ox86DD Internet Protocol Version 6 (IPv6) 

0x8847 MPLS 

0x8848 MPLS with upstream-assigned label 

0x8861 Multicast Channel Allocation Protocol (MCAP) 
0x8863 PPP over Ethernet (PPPoE) Discovery Stage 
0x8864 PPP over Ethernet (PPPoE) Session Stage 
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B.2. Some IEEE 802 Ethertypes 


0x8100 IEEE Std 802.10 - Customer VLAN Tag Type (C-Tag, formerly 
called the Q-Tag) 

0x8808 IEEE Std 802.3 - Ethernet Passive Optical Network (EPON) 

0x888E IEEE Std 802.1X - Port-based network access control 

0x88A8 IEEE Std 802.10 - Service VLAN tag identifier (S-Tag) 

0x88B5 IEEE Std 802 - Local Experimental Ethertype 

0x88B6 IEEE Std 802 - Local Experimental Ethertype 

Ox88B7 IEEE Std 802 - OUI Extended Ethertype 


0x88C7 IEEE Std 802.11i - Pre-Authentication 

Ox88CC IEEE Std 802.1AB - Link Layer Discovery Protocol (LLDP) 
0x88E5 IEEE Std 802.1AE - Media Access Control Security 
Ox88F5 IEEE Std 802.1lak - Multiple VLAN Registration Protocol 


(MVRP ) 

Ox88F6 IEEE Std 802.10 - Multiple Multicast Registration 
Protocol (MMRP) 

0x890D IEEE 802.11r - Fast Roaming Remote Request 
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